home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 305 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: peacock.tcinc.com!news
  2. From: Christopher Sweeney <csweeney>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: New C++ developers struggling with source configuration
  5. Date: 3 Jan 1996 15:56:56 GMT
  6. Organization: Tele-Communications, Inc.
  7. Message-ID: <4ce908$gcv@peacock.tcinc.com>
  8. References: <4ccfkd$7f5@azizia.dtm-corp.com>
  9. NNTP-Posting-Host: aitsun24.tcinc.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.12 (X11; I; SunOS 5.4 sun4m)
  14. X-URL: news:4ccfkd$7f5@azizia.dtm-corp.com
  15.  
  16. pierce@dtm-corp.com (Pierce Krouse) wrote:
  17. >We have a configuration problem brewing here where I work.  We have a
  18. >SCCS-based source code control system which has worked well in
  19. >developing C applications for unix platforms.  We have library and
  20. >application program source directories.  We are starting to develop
  21. >C++ classes and applications.  The big question is whether libraries
  22. >are the way to share classes between application programs, or if there
  23. >is a better way to let application programs get to class objects.  We
  24. >would prefer to have the Makefile that builds a given application
  25. >retrieve an object file rather than the source file (even though it is
  26. >all controlled under source code control).  The problem is
  27. >containment: several classes inherit or contain other classes, so we
  28. >cannot just give the application program a single object file -- or
  29. >can we?
  30.  
  31. Typically shared code is placed in archive (lib<something>.a) or shared
  32. (lib<something>.so) libraries.  The linker's job is to resolve references in
  33. your code and the libraries, including internal library references.
  34.  
  35. Unless you are not using the linker "properly", then the Makefile *does not*
  36. retrieve object files from libraries (regardless of C vs C++).  Thus, placing
  37. classes/etc. in libraries is fundamentally the same as placing C functions in a
  38. library.
  39.  
  40. The only caveat that I know of is Global Statics.  Global Statics are *suppose*
  41. to be initialized prior 
  42. to main being called (which is typically true).  The compiler/linker need to
  43. manage calling these initializers.  A while a go the SUN linker needed a
  44. "magic" .o explicitly added to the library so that the initializers would get
  45. called.  In later releases this requirement went away.
  46.  
  47. Note that global statics also have a problem with link-ordering in certain
  48. circumstances.
  49.  
  50. Hope this helps.
  51. C.
  52.  
  53.